Finding Differences in Privilege Protection and their Origin in Role-Based Access Control Implementations

Les applications Web sont très courantes, et ont des besoins de sécurité. L’un d’eux est le contrôle d’accès. Le contrôle d’accès s’assure que la politique de sécurité est respectée. Cette politique définit l’accès légitime aux données et aux opérations de l’application. Les applications Web utilisent régulièrement le contrôle d’accès à base de rôles (en anglais, « Role-Based Access Control » ou RBAC). Les politiques de sécurité RBAC permettent aux développeurs de définir des rôles et d’assigner des utilisateurs à ces rôles. De plus, l’assignation des privilèges d’accès se fait au niveau des rôles. Les applications Web évoluent durant leur maintenance et des changements du code source peuvent affecter leur sécurité de manière inattendue. Pour éviter que ces changements engendrent des régressions et des vulnérabilités, les développeurs doivent revalider l’implémentation RBAC de leur application. Ces revalidations peuvent exiger des ressources considérables. De plus, la tâche est compliquée par l’éloignement possible entre le changement et son impact sur la sécurité (e.g. dans des procédures ou fichiers différents). Pour s’attaquer à cette problématique, nous proposons des analyses statiques de programmes autour de la protection garantie des privilèges. Nous générons automatiquement des modèles de protection des privilèges. Pour ce faire, nous utilisons l’analyse de flux par traversement de patron (en anglais, « Pattern Traversal Flow Analysis » ou PTFA) à partir du code source de l’application. En comparant les modèles PTFA de différentes versions, nous déterminons les impacts des changements de code sur la protection des privilèges. Nous appelons ces impacts de sécurité des différences de protection garantie (en anglais, « Definite Protection Difference » ou DPD). En plus de trouver les DPD entre deux versions, nous établissons une classification des différences reposant sur la théorie des ensembles.----------ABSTRACT : Web applications are commonplace, and have security needs. One of these is access control. Access control enforces a security policy that allows and restricts access to information and operations. Web applications often use Role-Based Access Control (RBAC) to restrict operations and protect security-sensitive information and resources. RBAC allows developers to assign users to various roles, and assign privileges to the roles. Web applications undergo maintenance and evolution. Their security may be affected by source code changes between releases. Because these changes may impact security in unexpected ways, developers need to revalidate their RBAC implementation to prevent regressions and vulnerabilities. This may be resource-intensive. This task is complicated by the fact that the code change and its security impact may be distant (e.g. in different functions or files). To address this issue, we propose static program analyses of definite privilege protection. We automatically generate privilege protection models from the source code using Pattern Traversal Flow Analysis (PTFA). Using differences between versions and PTFA models, we determine privilege-level security impacts of code changes using definite protection differences (DPDs) and apply a set-theoretic classification to them. We also compute explanatory counter-examples for DPDs in PTFA models. In addition, we shorten them using graph transformations in order to facilitate their understanding. We define protection-impacting changes (PICs), changed code during evolution that impact privilege protection. We do so using graph reachability and differencing of two versions’ PTFA models. We also identify a superset of source code changes that contain root causes of DPDs by reverting these changes. We survey the distribution of DPDs and their classification over 147 release pairs of Word-Press, spanning from 2.0 to 4.5.1. We found that code changes caused no DPDs in 82 (56%) release pairs. The remaining 65 (44%) release pairs are security-affected. For these release pairs, only 0.30% of code is affected by DPDs on average. We also found that the most common change categories are complete gains (� 41%), complete losses (� 18%) and substitution (� 20%)

Taxonomy of Linux Kernel Vulnerability Solutions

This paper presents the results of a case study on software vulnerability solutions in the Linux kernel. Our major contribution is the introduction of a classification of methods used to solve vulnerabilities. Our research shows that error handling, redesign, and precondition validation are the most used methods in solving vulnerabilities in the Linux kernel. This contribution is accompanied with statistics on the occurrence of the different types of vulnerabilities and their solutions that we observed during our case study, combined with example source code patches. We also combine our findings with existing programming guidelines to create the first security-oriented coding guidelines for the Linux kernel

Security Evaluation and Hardening of Free and Open Source Software (FOSS)

Recently, Free and Open Source Software (FOSS) has emerged as an alternative to Commercial-Off- The-Shelf (COTS) software. Now, FOSS is perceived as a viable long-term solution that deserves careful consideration because of its potential for significant cost savings, improved reliability, and numerous advantages over proprietary software. However, the secure integration of FOSS in IT infrastructures is very challenging and demanding. Methodologies and technical policies must be adapted to reliably compose large FOSS-based software systems. A DRDC Valcartier-Concordia University feasibility study completed in March 2004 concluded that the most promising approach for securing FOSS is to combine advanced design patterns and Aspect-Oriented Programming (AOP). Following the recommendations of this study a three years project have been conducted as a collaboration between Concordia University, DRDC Valcartier, and Bell Canada. This paper aims at presenting the main contributions of this project. It consists of a practical framework with the underlying solid semantic foundations for the security evaluation and hardening of FOSS

ABSTRACT Slammer: Before, During and After

The internet was built to provide flexibility and easy connectivity. However, these qualities of the Internet raise major security concerns that they could be exploited to disrupt our daily lives. One such disruption was the spread of the Slammer/Sapphire worm, which happened on January 25 th, 2003. During the spread of the worm, many lost their internet connection, were not able to use ATMs, or saw their flights delayed directly due to the worm’s activity. In this report, we will study the Slammer worm in this ‘natural ’ environment: the Internet. We will study Slammer itself, the situation before the attack of the worm, the damage caused by its spread, as well as the lessons learned from this outbreak. We will approach this study mainly from a computer security point of view, while still presenting perspectives from the IT industry’s and the public’s viewpoint. Key Words